build(mac): bump webpack heap to 6 GB on the macOS appbundle build#9967
Merged
Conversation
macOS x64 appbundle builds keep dying inside webpack's TerserPlugin at 92% (asset processing). Build #1294 on `pgabf-macos-x64` reached `<s> [webpack.Progress] 92% [0] sealing asset processing TerserPlugin` and was killed without producing a V8 fatal-error preamble, which points at the OS reaping the Node process under memory pressure rather than V8 hitting its own heap ceiling. TerserPlugin is already running single-threaded (see web/webpack.config.js, `parallel: false`), so we can't claw memory back by reducing parallelism. Bump the V8 old-space ceiling from 3072 MB to 6144 MB inside the macOS appbundle build only — the helper in pkg/mac/build-functions.sh bypasses `yarn run bundle` and calls `yarn run webpacker` directly (see commit d96e863), so this knob is independent of the npm script and does not affect linux/pip/Makefile or dev-machine builds. They keep the 3 GB the `bundle` script has been shipping with for years. If this still doesn't get the x64 box past Terser we'll switch the minimiser to esbuild via terser-webpack-plugin's `minify` option; that is a larger and more invasive change so we are trying the cheap fix first.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
WalkthroughThe PR updates the macOS build script to increase the V8 engine's old-space memory limit during webpack bundling from 3072 MB to 6144 MB, adjusting the corresponding documentation comments to reflect this larger memory allocation. ChangesMemory Configuration Update
Possibly related PRs
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
3 tasks
asheshv
added a commit
that referenced
this pull request
May 22, 2026
…9968) The 6 GB ceiling set by #9967 was too aggressive for the macOS x64 VM's total RAM. Build #1295 on `pgabf-macos-x64` failed in `_build_runtime` at `unzip electron-vX.X.X-darwin-x64.zip` with exit code 2 — never even reached webpack. That points at OS-level memory pressure spilling out of the Node process and starving the rest of the build: at 6 GB reserved, the box runs out of RAM long before Terser actually needs the full ceiling. Drop back to 4 GB, which still gives Terser a full extra gigabyte beyond the original 3 GB setting that OOM-killed webpack in #1294, but leaves enough headroom for the other steps in the appbundle build to coexist. Only the macOS appbundle path changes (see pkg/mac/build-functions.sh); linux/pip/Makefile and dev-machine builds keep the 3 GB the `bundle` npm script ships with.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
TerserPluginat 92% (asset processing). Build #1294 onpgabf-macos-x64reached<s> [webpack.Progress] 92% [0] sealing asset processing TerserPluginand was killed with no V8 fatal-error preamble — pointing at the OS reaping the Node process under memory pressure rather than V8 hitting its own ceiling. (Diagnostics are visible thanks to build(mac): split bundle step and capture stderr for diagnostics #9965.)TerserPluginis already running single-threaded (parallel: falseinweb/webpack.config.js), so we can't claw memory back by reducing worker count. Bump V8's old-space ceiling from 3072 MB to 6144 MB inside the macOS appbundle build only.pkg/mac/build-functions.sh::_complete_bundle, which already bypassesyarn run bundleand callsyarn run webpackerdirectly (see d96e863). So this knob is independent of the npm script and does not affect linux/pip/Makefile or dev-machine builds — they keep the 3 GB that thebundlenpm script has been shipping with for years.Test plan
pgadmin4-macos-qaon bothmacos-x64andmacos-arm64and confirm the appbundle now builds successfully end-to-end.92% [0] sealing asset processing TerserPluginand reachesemitting/donewithout truncation..dmgsize on x64 vs arm64 to confirm both bundles are intact.If this doesn't work
The next step would be switching the minimiser from Terser to esbuild via
terser-webpack-plugin'sminifyoption (much lower memory). That's a larger, more invasive change, so this cheap fix goes first.Summary by CodeRabbit